Add the onoff attribute cluster to ts004f by elupus · Pull Request #4537 · zigpy/zha-device-handlers

elupus · 2025-11-30T01:33:41Z

Proposed change

Restore OnOff cluster on TS004F:
These attributes are not available on the output side, only on the input side.

This fixes warnings about direction being wrong on the onoff cluster, since
the onoff cluster was removed on the input side.
Restore standard name on the TuyaSmartRemoteOnOffCluster cluster.
This is still a standard On/Off cluster, it just have some extensions.

Additional information

I have tested reading of the switch_mode attribute from this, which now works as expected.

Depends on: zigpy/zha#591 to ensure the OnOff cluster does not end
up adding a switch entity.

Depends on: zigpy/zha#590 to make sure this is added as a select entity

Device diagnostics

Checklist

The changes are tested and work correctly
pre-commit checks pass / the code has been formatted using Black
Tests have been added to verify that the new code works
Device diagnostics data has been attached

codecov · 2025-11-30T01:35:21Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.32%. Comparing base (04c61bb) to head (b84f044).
⚠️ Report is 85 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #4537      +/-   ##
==========================================
- Coverage   92.32%   92.32%   -0.01%     
==========================================
  Files         371      371              
  Lines       12198    12196       -2     
==========================================
- Hits        11262    11260       -2     
  Misses        936      936

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

elupus · 2025-11-30T01:49:23Z

@MattWestb Do you remember why you added this attributes to the output side of this cluster? The rotation events seem to come from the output cluster, but the attribute data is on the input cluster.

Feel like we should remove those attributes from the output cluster (TuyaSmartRemoteOnOffCluster)

elupus · 2025-11-30T02:04:20Z

This looks like it should not be a complete OnOff cluster on input here, since not all attributes are supported on input and we end up creating a switch entity.

elupus · 2025-11-30T03:01:38Z

This will depend on zigpy/zha#590

MattWestb · 2025-11-30T09:28:55Z

Hej du glade !!

Im not one code worrier and more "copy and paste / try and fail" but we was starting with the dimmer switch that is only having the short and long press commands but it was one long road getting there.
The device is only having one EP then being paired and cant initiating the other 3. After sniffing we was finding that tuya is sending some attribute reads and the device is being initiated as one scene controller (tuya magic) (the EP1-4 is not visibly then init the device but is working so the quirk looks very strange).
Happy we was adding the light commands we was seen and also implanting the attribute for switching working more (also possible do on the device).
The was not getting group binding working and finding that tuya is doing it ad the device is one light and adding one (only the last is added s working) the device is sending light commands to light OK. The large problem was in scene mode the device need default response in wrong direction that was not possible doing in ZHA at that time > the device can waiting for DfRs but it timing out before sending sending next scene command (i think this is only one EP 2-4 and was working OK on EP1).

Next was the rotating knob that we was decoding and only adding the new commands it was sending and it was looking working OK but no deep diving so more then likely it can being in wrong direction like tuya oft have done.

In the end the deleting the On/Of in cluster so THA is not doing one light in the GUI.
First deleting the group in cluster but was finding its need it then dont support Zigbee binding and must being treated as one light.

I have one dimmer switch and one rotating knob so can doing testing and sniffing if you need more info for debugging the problem.

MattWestb · 2025-11-30T09:45:26Z

By the way if you like doing some more deep fixing it shall being possible implanting the matter switch functionality for the scene commands its sending like IKEA was doing on Symfonisk 2 and sommrig and is exposed from Dirigera (the real matter commands was implanted on one manufacture cluster then it was not on the current matters spec) as switch entrees with last status:

I also think (have not looking in the latest matter (Z)Cluster Library) Matter shall have implanted rotary sensor that can being nice for the knob.
But we shall knowing in one week then Bilresa is start selling in some regions (5 December in Sweden Austria perhaps little later for me).

Edit: Correcting my Sw gramma: Not Bilresa (Eng Car trip) then its more then one device IKEA is releasing so its shall being Bilresor !!! (Eng Car tripos)

Edit2:
Not found rotary in "Matter Device Library Specification Version 1.4.2-mve-1" but keep looking !!

elupus · 2025-11-30T12:27:34Z

Anyway you can test reading writing of the switch mode on any of the devices you have? And see if you get any data from that attribute when it's on output endpoint? I cant get that to work on any of the ts004f.

(I would like to remove it from the output cluster if possible)

MattWestb · 2025-11-30T13:47:51Z

Was reading all attributes on Clusters:
TuyaSmartRemoteOnOffCluster (Endpoint id: 1, Id: 0x0006, Type: out)
and only cluster_revision (id: 0xfffd) was returning 1 and all other none.
Then changing the "swish mode" on the device ZHA is logging:
TS004F ROK Attribute Updated event was fired so something looks being broken in current ZHA.

Edit: Writing 0 or 1 say OK but no working mod not changed on the device and no attribute changed in ZHA log.
=> 2 is giving error = OK

elupus · 2025-11-30T14:00:44Z

Good then it looks like it works same as I see it. If you also add the onoff cluster or the attribute cluster on input side it works. (The events still must be on output side)

Maybe there was some compatibility that switches direction of a cluster command that was removed (the warning that is logged).

MattWestb · 2025-11-30T14:07:09Z

The TS004X devices is having the same defect (and some other tuya devices) so i think they is also have lost some functionality from ZHA but still working on the device then its possible doing it.

These attributes are not available on the output side, only on the input side. This fixes warnings about direction being wrong on the onoff cluster, since the onoff cluster was removed on the input side.

The cluster is a normal On/Off cluster with some extensions.

MattWestb · 2026-01-31T09:44:04Z

    TURN_OFF,
    TURN_ON,
 )
+from zhaquirks.quirk_ids import TUYA_PLUG_ONOFF


I dont understand the logic of this naming then the tuya scene commands is only being used of scene remotes and no plugs what i knowing.

This may not be needed anymore. I think i originally used it to match some cluster handler.

Forgot this was not i draft. Will remove that change.

Actually.. Some way to mark the cluster having the "switch_mode" attribute is needed. The name of the quirk is bad thou.

The OnOff cluster have extensions. It's still a standard OnOff cluster on both client and server side.

Also I don't think we need to have TuyaSmartRemoteOnOffCluster and TuyaZBOnOffAttributeCluster. They are really only the server and the client side of same cluster. All other clusters are combined to describe both sides.

Most tuya quirk is in the pipe for being converted to V2 but its great that you is digging it it so some is knowing how the device is working and can getting the code catching it.
Sadly tuya is doing there "zigbee" implantation that is mostly OK but have making very bad shortcuts like on this devices is not supporting binding in the normal way (binding cluster to devices and / or groups) instead adding ther as lights that is out of all standards.
And thanks for your work done !!

Most logic is renaming the TUYA_PLUG_ONOFF if its being used for other device types then plugs (the first use of the old cluster was for the TS004F and then extended for the plugs and adding the back light and children lock).

MattWestb · 2026-01-31T16:17:50Z

All TS004F devices is needed this for understanding the "scene commands".

zha-device-handlers/zhaquirks/tuya/__init__.py

Lines 1048 to 1060 in 04c61bb

    
           class TuyaSmartRemoteOnOffCluster(OnOff, EventableCluster): 
        
               """TuyaSmartRemoteOnOffCluster: fire events corresponding to press type.""" 
        
               rotate_type = { 
        
                   0x00: RIGHT, 
        
                   0x01: LEFT, 
        
                   0x02: STOP, 
        
               } 
        
               press_type = { 
        
                   0x00: SHORT_PRESS, 
        
                   0x01: DOUBLE_PRESS, 
        
                   0x02: LONG_PRESS, 
        
               }

Plus the now not working attribute you is fixing here.
Only look what is needed then i remember the device is not sending commands in the right direction but if you can getting it working without the warnings its being great.

The quirks naming was from the start from the tuya is naming its devices that can being found in there dev docks but many have doing new quirks with other names / meanings.

This is just two sides of the same cluster and such are normally handled as a single cluster definition.

elupus · 2026-01-31T21:26:02Z

How about this change? I merged the two OnOff cluster's since it was just client side and server side of same extensions and regenerated the test cases in zha and it only render very minor changes for the testcases there.

Ps. The scene stuff there are just standard server commands sent same as any other levelcontrol/onoff, just a manufacture specific extension to the OnOff. Ie they are not doing anything strange with those. Can easily be handled as event entities once we have those changes in.

elupus mentioned this pull request Nov 30, 2025

Add tuya switch_mode for rotary knobs zigpy/zha#590

Draft

elupus added 3 commits January 31, 2026 01:05

Add the onoff attribute cluster to ts004f

054379f

These attributes are not available on the output side, only on the input side. This fixes warnings about direction being wrong on the onoff cluster, since the onoff cluster was removed on the input side.

Add tuya plug quirk

69c09fb

Restore name of tuya smart remote cluster

fbc4627

The cluster is a normal On/Off cluster with some extensions.

elupus force-pushed the tuya/smart_knob branch from 0ad7af7 to fbc4627 Compare January 31, 2026 00:42

MattWestb reviewed Jan 31, 2026

View reviewed changes

Merge the Tuya on off clusters into one

b84f044

This is just two sides of the same cluster and such are normally handled as a single cluster definition.

TheJulianJES added Tuya Request/PR regarding a Tuya device needs review This PR should be reviewed soon, as it generally looks good. labels Mar 25, 2026

Conversation

elupus commented Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed change

Additional information

Device diagnostics

Checklist

Uh oh!

codecov Bot commented Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

elupus commented Nov 30, 2025

Uh oh!

elupus commented Nov 30, 2025

Uh oh!

elupus commented Nov 30, 2025

Uh oh!

MattWestb commented Nov 30, 2025

Uh oh!

MattWestb commented Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elupus commented Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MattWestb commented Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elupus commented Nov 30, 2025

Uh oh!

MattWestb commented Nov 30, 2025

Uh oh!

MattWestb Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

elupus Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

elupus Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

MattWestb Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

MattWestb Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

MattWestb commented Jan 31, 2026

Uh oh!

elupus commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

elupus commented Nov 30, 2025 •

edited

Loading

codecov Bot commented Nov 30, 2025 •

edited

Loading

MattWestb commented Nov 30, 2025 •

edited

Loading

elupus commented Nov 30, 2025 •

edited

Loading

MattWestb commented Nov 30, 2025 •

edited

Loading

elupus commented Jan 31, 2026 •

edited

Loading